IBIS Macromodel Task Group

Meeting date:20 July 2021

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Jared James
Google:                       Zhiping Yang
Intel:                        Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
                            * Ming Yan
                              Todd Bermensolo
                            * Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Micron Technology:          * Randy Wolff
                              Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:
  
- None.

-------------
Review of ARs:

- Fangyi to send BIRD211.3 draft 2 to ATM for final review.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the July 13th
meeting.  Walter moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD211.3 draft2:
Fangyi shared the draft.  Bob noted that references such as, "On page 201 after
section 10.2.3" might need to be adjusted, since this BIRD will now be relative
to IBIS 7.1, not IBIS 7.0.

Bob said he was still unclear about the paragraph that starts with:
  Note that EDA tools, for AMI models with AMI_Version 7.2 and later, are
  allowed to determine the model filter impulse response by adding an aggressor
  column that contains a "unit impulse response" to determine the filter
  equalization.
  
He asked how this was related to Tx_Impulse_Input.  Others replied that this is
independent of the Tx_Impulse_Input parameter.  The aggressor columns have
always been available, but IBIS 7.1 will be the first time the specification
states that model makers should be aware of and handle the possibility of an EDA
tool passing in a "unit impulse response" dummy aggressor column.  Walter noted
that tools could always have employed this technique, at their own peril, and
since no known AMI model optimizes its equalization based on crosstalk it would
be fine.  Only a future model that optimizes its equalization settings based on
crosstalk columns would have to worry about special handling of a unit impulse
response dummy column.

Ambrish moved that we delay the final review until next week, so everyone has
time to fully review draft2.  Bob seconded.  There were no objections.

PAMn BIRD213 discussion:
Walter said he had made some additions to a BIRD213.1 draft, and he briefly
reviewed them.  He noted that one major addition was a definition and
explanation of duobinary.  Walter observed that you don't get more data per
UI with duobinary, like you do with other PAM3 flavors, or PAM4, etc.  But
duobinary makes sure your voltages stay centered around zero, so you don't
have issues with DC drift.

Arpad asked if PAM3 and duobinary are two different things.  Walter said both
have 3 levels, but it's a question of how the levels are mapped.  One typical
PAM3 is the 11/7 encoding, where 11-bit patterns are mapped to 7 three-level
symbols.  In duobinary you get a one to one mapping of bits to symbols, no
density gain in terms of information per UI.

Fangyi said he disagreed with the stated definition of duobinary.  He said
another implementation is an adder that adds the previous bit to the current
bit, and it is like a low-pass filter that effectively lowers the bandwidth
of the signal.  Fangyi said there are many flavors.  Walter agreed and said we
could leave the definition as a future exercise and plan to expand and refine
it.

Arpad asked, if there were many flavors of doubinary, and many mappings for bits
to symbols in other PAMn schemes, then what's the best approach for handling
them in the specification?  He said it's probably not good to try and enumerate
all the possibilities.  Would something with expressions or equations be more
appropriate than static tables and allow us to include dependence on previous
bits?

Walter reviewed the PAM_Mapping_Table and the examples showing how each row
in the table maps an M-bit binary pattern into a pattern of N n-level symbols
(e.g., M=11, N=7, n=3,  for the 11/7 PAM3 mapping).  Fangyi noted that this
approach works when the mapping does not depend on previous history.  Walter
agreed that it doesn't work for duobinary, for example, and we will have a
special case for that.

Arpad asked if the 11 bits (11/7 example) in each row's bit pattern are
successive bits in time.  If so, is the right-most bit the first in time or the
left-most?  Fangyi and Walter agreed that this was a good question and we should
clarify the intent.

Curtis asked if we would really want to have to specify 2048 lines (2 to the
eleventh) to enumerate each of the possible 11-bit patterns in 11/7.  Ambrish
asked what the point of the table was and whether we should be enumerating such
things inside the specification.  Walter said he had originally thought we
should not include the mapping in the specification, but others had argued to
include it in his BIRD.  He said a tool might randomly generate 3-level symbol
patterns for a PAM3 case, but there is the issue that not all 3-level sequences
are allowed.  Do we care?  You might also generate a mapping that avoids the
"lonely 1" bit pattern that can cause problems with drift and other issues, for
example.

Ambrish asked if the IBIS specification is where we should be defining the
specifics of the mappings.  Arpad agreed and said this went back to his question
about whether or not we should be trying to hard code every flavor and enumerate
things in the specification.  Walter suggested we could simply provide the
PAM_Mapping_Name, and another document could provide the definitions of the
mappings.  Arpad said the BCI protocols provide a precedent for having
externally supplied definitions.  Walter said that this case is slightly
different, since the tool will have to be aware of the PAMn mapping details.
Fangyi suggested we might just define the names and expect that the tools should
know what they mean.  Walter asked, who would be the keeper of the official list
of supported names?  Randy noted that we hadn't yet really solved the issue with
respect to a process for publishing BCI protocols, but that we might do
something similar here.

- Randy: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.

AR: Walter to send BIRD213.1 draft 2 to ATM for people to review.

-------------
Next meeting: 27 July 2021 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
